Para empezar cabe aclarar que el frontend de DWall está desarrollado con Vue 2 (v2.5) junto con vue-router 3 y Vuex 3. En el momento de inicio del TFG, Vue 2 se encuentra en fin de vida (end of life desde diciembre de 2023), aunque la migración hacia Vue 3 todavía no está en curso. Todo el desarrollo del TFG, al igual que el trabajo de prácticas previo, se realiza íntegramente sobre Vue 2.
Tras analizar el funcionamiento interno del módulo de descripciones, proseguiremos con su diseño en el frontend. Este se encuentra dentro del workspace bajo la ruta /description.
En este 'workspace' o zona de trabajo se encuentran todas las herramientas para gestionar los recursos por defecto de DWall, las mismas que hemos analizado en el anterior capítulo: variables, variables agregadas, reglas etc. Con la excepción de recursos de usuarios y grupos cuya disponibilidad está limitada al módulo de ajustes (son necesarios permisos extra).
En esta misma imagen se puede observar la interfaz del /workspace, en este mismo los botones de ir al menú de descripciones y el de los archivos.
Vistas de descripciones
El menú de descripciones alberga la ubicación donde los usuarios de DWall asignan descripciones a los diferentes recursos de la plataforma.
Este, DescriptionMenu, es un menú de navegación que actúa como hub visual hacia las distintas secciones. Está compuesto por tarjetas, cada una con un icono de FontAwesome y un título traducido vía $t() (forma de traducir texto a diferentes idiomas automaticamente), envueltas en un componente SafeWithElseRouterLink — un wrapper sobre <router-link> que gestiona de forma segura rutas deshabilitadas o no disponibles.
Vistas de edición
Cada vista de edición sigue el mismo patrón: un selector para elegir el recurso concreto y un campo de texto para redactar o editar su descripción. El mounted() del componente está vacío — no se carga nada al entrar en la vista. La carga ocurre únicamente cuando el usuario selecciona un recurso en el selector, momento en el que se dispara el evento close del componente LabelVariableSelector y se ejecuta el método putDescription.
Este realiza dos llamadas secuenciales a la API: primero obtiene el id de la descripción (getDescriptionId) y con él recupera el texto (getDescription). Si el recurso no tiene descripción, el campo simplemente queda en blanco. El selector incluye búsqueda con debounce de 300 ms para no saturar la API en cada pulsación de tecla.
En la misma imagen se puede observar los campos a rellenar para otorgarle descripción a los recursos.
Al guardar, el componente valida que ambos campos estén rellenos antes de llamar a description.save. Si la validación pasa, muestra una alerta de éxito y redirige automáticamente al DescriptionMenu.
Pese a que esta lógica esté alineada con el deseo de que el módulo de descripciones sea una característica totalmente opcional en las marcas, tiene un problema visible: no es funcional editar individualmente las descripciones de los recursos después de su creación, ya que para ello habría que navegar expresamente a esta vista, buscar el recurso y modificarlo.
Esto supone que ya durante el periodo de prácticas se empezarán a añadir campos en los mismos recursos para que la descripción se añadiera en la misma creación del recurso (se verá más adelante).
Vista global: SeeAllTheDescriptions
La vista SeeAllTheDescriptions consume el endpoint getAllNamedDescriptions y muestra una tabla paginada con todas las descripciones del sistema, independientemente del tipo de recurso:
| Columna | Contenido |
|---|---|
| Tipo | VARIABLE, AGGREGATE, TAG, QUERY, RULE, USER, GROUP, FILE |
| Nombre | Nombre legible del recurso (obtenido de la tabla mirror) |
| Descripción | Texto de la descripción |
| Usuario | Quién la creó |
| Fecha | Timestamp de última modificación |
La tabla permite filtrar por nombre, descripción y tipo, y ordenar por cualquiera de las columnas. El componente DescriptionTable es reutilizable y está diseñado para ser embebido en otras vistas si fuera necesario.
Esta misma tabla será más adelante la responsable de gestionar el módulo completo de descripciones. Junto, claro está, un campo extra a la hora de crear cada uno de los recursos para añadir su respectiva descripción.
Capa API
Las llamadas al backend se centralizan en un único archivo /src/api/description/index.js y cubren las operaciones CRUD estándar: guardar, actualizar, eliminar y consultar descripciones. El endpoint más relevante es getAllNamedDescriptions, que combina la tabla central con las tablas mirror para devolver el nombre legible de cada recurso — conectando directamente con el patrón mirror descrito en el subcapítulo de backend.